The present invention relates to data storage systems. In particular, the present invention relates to a system, structure and procedure for customizing an array controller""s operating software before downloading the operating software onto the array controller.
Disk drives in all computer systems are susceptible to failures caused by temperature variations, head crashes, motor failure, controller failure, and changing voltage conditions. Modern computer systems typically require, or at least benefit from, a fault-tolerant data storage system, for protecting data in the data storage system against any instances of disk drive failure. One approach to meeting this need is to provide a Redundant Array of Independent Disks (RAID).
RAID is a known data storage technology. A typical RAID system includes a disk array controller (controller) coupled across both an input/output (I/O) bus to multiple disk storage devices (known as a disk array), and coupled across another I/O bus to the one or more host computers. The controller processes I/O requests from the one or more host computers to the disk array. Such I/O requests include, for example, Small Computer System Interface (SCSI) I/O requests, which are known in the art.
To configure a RAID system, an end-user will first typically determine how may units of storage, or respective storage subsystems are needed to realize one or more purposes of the RAID system. For example, the purpose of a first storage subsystem may be used to increase the capacity of a general-purpose file and print server. The purpose of a second storage subsystem may be used to support a database application that has to keep running 24 hours a day. The purpose of a third storage subsystem may be used to playback on demand large files of audio or video clips. And, the purpose of a fourth storage subsystem may be used to store image data for an imaging system.
Next, an end-user will typically organize the disk storage devices into a number of storage subsystems necessary to meet the determined purpose(s) of the RAID system, where, if there is more than one such storage subsystem, each storage subsystem may have a different storage capacity as compared to the storage capacity of another storage subsystem. For each storage subsystem, depending upon the determined purpose of each respective storage subsystem, the end user will select a particular RAID technology for the controller to manage the I/O between the one or more host computers and each respective storage subsystem. The particular RAID technology selected to manage a storage subsystem may provide, among other things, a level of reliability to the storage system in the event of one or more disk storage device failures, and compliance with any access parameters necessary to implement the respective storage subsystems""s purpose. (Certain RAID technologies do not provide data redundancy).
A controller will use one or more different RAID technologies, or RAID levels 0-5, to stripe, or divide data from a host computer into data segments and distribute the data segments across the disk storage devices in a storage subsystem in a well-defined manner. As a result of data striping, the disk storage devices that make up a data storage subsystem become, in effect, one logical storage unit as far as a host computer is concerned. The numerical RAID levels 0-5 refer to different data striping techniques that balance various levels of storage subsystem capacity, data availability and I/O performance. Thus, depending on the particular RAID level selected by an end-user to manage the one or more storage subsystems, a controller will use a different access profile, or technique with respect to how it will manage the type and frequency of I/O activity that is performed against the disk storage devices in the storage subsystem over the course of time.
To facilitate the configuration and maintenance of a RAID system, a controller typically includes a RAID system configuration architecture that is stored on a hardware device (non-volatile RAM or firmware) that includes computer instructions (configuration code) and data. Such a configuration architecture typically supports all possible RAID system configurations that an end user may require. Because such an open ended configuration architecture must implement all possible combinations of RAID system configurations, the accompanying configuration code is generally very complex involves large amounts of code. Such complex configuration code presents a number of significant problems.
For example, one problem with such complex code is that is very difficult and time consuming to modify, because there is no prior art that allows an end user or computer programmer to modify such code without sophisticated computer programming tools. If the configuration code resides in read only firmware, it cannot be modified at all. Another problem with such complex configuration code is difficult to maintain. This is because field upgrades, that is upgrading the configuration code in a controller to benefit from another version of the configuration code, are impractical when the controller has already been distributed to an end-user.
Another problem with such complex configuration code is that it is difficult to comprehensively test both for errors in programming logic and for potential errors that may result from illegal end user input parameters. To ensure that the configuration code is properly designed, the logic for each possible hardware, RAID level, and end user input combination should be tested, which is a time consuming and highly specialized process.
To appreciate the typical testing process, consider that the number of configurations to test is equal to xe2x80x9cknxe2x80x9d, where xe2x80x9ckxe2x80x9d is equal to the number of choices you have for each option, and xe2x80x9cnxe2x80x9d is equal to the number of different configuration options. For example, consider a data storage system where only eight (8) devices, for example, 8 virtual disk storage devices, need to be configured and wherein each device has up to five (5) different configuration options, for example 5 RAID levels. In such a system, the number of configurations to test is equal to 58 (xe2x80x9cknxe2x80x9d), or 390,625 possible configurations to test. Because, a typical data storage subsystem has more than eight different devices, and often more than one-hundred (100) different devices that may be configured, it can be appreciated that testing such complex code a time consuming and highly specialized process.
Another problem with such complex configuration code is that it degrades controller I/O processing performance. Controller I/O processing performance is related to the number of processor clock cycles that are required for a processor in the controller to execute an instruction. Because the configuration code is traditionally open ended and flexible, it must necessarily make many real-time decisions as to how the data is going to be accessed, retrieved, and/or stored across a RAID system. Each of these decisions are generally implemented in the configuration code with conditional statements. Because conditional statements typically require more processor clock cycles to execute as compared to other types of statements, these many run-time decisions degrade controller I/O processing performance.
Yet another problem with such complex configuration code is that it has a large code footprint, meaning that a large amount of memory resources are respectively required to store and execute configuration code that includes logic for all possible RAID system configurations. Because large amounts of memory are expensive, it is desirable to keep such memory requirements to a minimum.
What is needed is a system, apparatus and procedure for an end user to conveniently customize and download the configuration code in a controller""s configuration architecture to reflect the end-users desired RAID system configuration. It is desirable for such a customized configuration architecture to not include logic to support all possible RAID data storage system configurations. As a result, the customized configuration architecture will be simpler, as compared to traditional configuration code, to modify, maintain, and test.
Desirably, the customized controller configuration architecture will increase a controller""s I/O performance as compared to typical controller I/O performance, because it will not include conditional logic to computer instructions that support configurations that do not apply to the end users desired system configuration. Desirably, reduced number of computer programmed instructions in the customized controller architecture will reduce the amount of memory that is required for a controller to respectively store and execute the configuration code, as compared to the amount of such memory that a controller typically requires to store and execute such code.
The present invention provides a procedure to configure the operation of the a device controller. In particular, the procedure operates in a system that includes a controller that is connected across a first input/output (I/O) interface to at least one other controlled device. In one embodiment, an auxiliary computer is connected to the controller by a second I/O interface. The auxiliary computer has a processor therein for executing a set of computer program instructions stored in a first memory. The computer program instructions cause the auxiliary computer to first identify a set of resources in the system. Next, the auxiliary computer determines a set of compatible configuration options that are compatible with the identified resources. Next, the auxiliary computer generates an executable procedure from a number of software procedures that are stored in the memory of the auxiliary computer to implement the compatible configuration options. Finally, the auxiliary computer communicates the executable procedure into a second memory of the controller as controller configuration code.